[セッションレポート] RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法 #jawsdays #jawsug #jd2019_g

こんにちわ。崔です。

先日開催されたJAWS DAYS 2019 、Gトラックで行われた下記セッションをレポートします。AWS DMSを使ってサービスを止めずにRDBををリファクタリングする手法について、そのノウハウが公開されました。

• RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法

スピーカー

• 曽根 壮大さん / 株式会社 オミカレ

株式会社オミカレはRDS上のAuroraからPostgreSQLへ Amazon Database Migration Serviceを使って異種間DB移行をしています。 その中で得た次のようなノウハウを余すことなくお伝えします。

資料

内容

リファクタリングする理由

テーブルを眺める会

• このテーブル何？
• 誰も知らないテーブル
• ８年目のWebサービスのため、多くの変化により技術的負債が出来た

主な技術的負債

• 誰も知らないテーブル
• 不適切な値の入ったレコード
• 制約がなく、壊れた整合性
• 非正規化によって、複雑化したコード

リファクタリングする理由

• 自分達で技術で解決

リファクタリングするための要件

• 無停止
• 同時には直せない
• 工数は限られる

リファクタリング方針

• トリガーを使って肥大化したテーブルを分割する
• 既存スキーマからトリガーを介して、新スキーマに分割された複数のテーブルに書きこむ
• しかしながら、Aurora MySQL ５.６互換では、１つのテーブルに対して、同じイベントには複数のトリガーを設定できない
• PostgreSQLならトリガーが使える

RDS for PostgreSQLの採用

• トリガーを複数設定できるRDBMS
• Aurora PostgreSQLの情報の少なさ
• AuroraはAuroraであり、OSSではない
• ローカルで同じ開発環境を用意できない
• Extensionの自作が必要かもしれない

DMSを選んだ理由

主なタスクの種類

• 全ロード＋継続的なレプリケーション（CDC）ができる
• binlogやWALを基に差分レプリケーション
• オミカレで利用しているのはココ
• 継続的なレプリケーション（CDC）のみ
• 全ロードのみ

タスク実行単位の指定方法

• 正規表現でのテーブル名指定
• 移行ルールの指定
• 移行元と移行先でテーブル名が違う場合
• 対象データをWhere句で絞り込む

他の製品を諦めた理由

• ライセンスコストが高い
• 技術介入度が高い
• 運用コストが高い
• 技術サポートがない
• リスク高い

サービスを止めるな

実際に運用してみて

• データ量が少ないなら簡単
• DMSはローリングアップデートも可能
• Postgre9.4 から10.0への移行も可能

参照を切り替える

• API経由にすることでModel単位に

この方法のメリット

• Model単位での移行が可能
• 対象のテーブル単位でできる
• リスク範囲を小さく
• 既存の仕組みを止める必要がない
• カナリヤリリース出来る
• ロールバックしやすい
• 概ねリスク低く対応
• 読み込みだけAPIにして書き込みはOLDへ
• 書き込みはAPIとOLDの両方に書き込み、読み込みはOLD

この方法のデメリット

• ローカルで再現出来ない
• DMSが単一障害点
• 遅延したりすることがたまにある
• トリガーが失敗するとDMSが止まる
• Aurora リードレプリカが昇格に未対応
• エンドポイントが変わるとDMSが止まる
• DMSのタスクの上限がある
• 開発環境を無限には作れない
• 現状は本番で20以上のタスクが動いている

実運用してみて

• 時々DMS止まる
• データ登録時のエラーを監視
• RDSのログをPHP経由で定期的にチェックする
• 1．downloadDBLogFilePortion関数を実行
• 2．Errorなどの特定のキーワードを拾ってalert
• 3．Mackerelのチェック監視の仕組みで通知

実運用してわかったこと

• 性別がintではなく文字列のため表記ゆれ
• MySQLのZero Date問題
• タイムゾーンがUTCでズレる
• 想定外のデータは以外とある
• 細かい制約と監視・観測で潰していく

まとめ

• Amazon DMSは便利なツール
• 異種間でなくてもユースケースは多い
• バージョンアップ、複数DBの集約、データセンターからの移行など
• しかし、一時的利用をするツール
• 更新が激しい場合は、レプリケーションが追いつかないことも

まとめ２

• 諦めず仕組みで解決していく
• 仕組みは技術力で解決できる
• 技術で問題を解決していく

所感

Aurora MySQL ５.６ 上で動くデータベースをどのようにリファクタリングしたか、RDS for PostgreSQLでトリガーを使う方法や、DBレプリケーションにDMSを使った手法が紹介されていました。

また、DMSを使うメリット／デメリットや、レプリケーション後のDBを参照させるための工夫についても、実際の苦労点含め、非常に参考になりました。

異種間DBのレプリケーションを行う際には、AWS DMSは第一の選択肢になると思います。そのような機会があれば、まずはテストで試してみることをお勧めします。